Field of the Invention
The present invention relates to systems and methods for establishing data communication between electronic devices. More specifically, the present invention includes systems and methods for establishing bi-directional data communication between electronic devices and for establishing uni-directional and bi-directional communication between devices and peripherals.
Description of the Related Art
In the field of computerized devices, there are many different interface ports used for communication. RS-232 serial communication, for inter-terminal communication over copper wires, was standardized in 1969. Since that time, many additional wired and wireless techniques have been developed for inter-device communication.
In recent times, there has been a proliferation of mobile devices. The 1990s saw the emergence of PDAs (personal digital assistants), and the last 10 years have seen the emergence of “smartphones”, phones with a general-purpose central processing unit capable of running multiple simultaneous programs, much like a computer. Similarly, portable media players (PMPs), such as the iPod have developed computer-like functionality. In the last several years, over a billion mobile phones have been sold each year, and an increasing number of these phones are being designed as “smartphones”, incorporating general-purpose computing technology coupled with an always-on Internet connection.
Because these devices are in essence portable computers, they are used for conventional computer functionality, including email, address book, calendaring, and document manipulation. There are various ways to get this sort of information onto portable devices and to connect peripherals to such devices. Unfortunately, all of the current methods have limitations with regards to nearby, immediate, low-latency connectivity.
Because these devices are in essence portable computers, the manufacturers have allowed a controlled level of third-party application development on their platforms. Examples of mobile platforms include the Microsoft® Windows® Mobile platform, the Symbian platform, the Palm® Palm OS® and web OS™ platforms, the Google™ Android™ mobile application platform and the Apple® iPhone® OS platform. Each of these mobile device operating systems resembles in many respects a traditional desktop computer operating system. However, the internals of many of these operating systems are restricted in such a way that new device drivers—the software that allows for additional hardware devices to be connected or for additional network protocols to be implemented—are not permitted.
The smartphone type devices communicate to the Internet using the TCP/IP protocol and to other devices such as computers and printers through local-area and wide-area wireless networking. Hardware transmission standards that support this include Wi-Fi (802.11); cellular wireless networking such as CDMA, UMTS, HSDPA, GPRS and EDGE; and wide-area networking such as WiMAX (IEEE 802.16). However, device-to-device and device-to-peripheral communication is awkward with these standards. To have two devices communicate in this manner, they must either communicate through an intermediary server or website (the most common method), adding delay and complexity of setup. For instance, if one device is to send a single contact of an address book to another device—for example, in exchanging business contact information—there is no straightforward technique for sending the contact directly, and the most common alternative, sending the contact over email, is less direct and not instantaneous, and may not even be supported by one of the devices.
If devices are to communicate in a peer-to-peer manner (i.e., sending network packets directly from one device to another), it is necessary to have both devices communicate with the same network protocols and the same application-layer protocols, and to solve issues such as network peer discovery. In practice, due to concern about viruses inherent in any network protocol, devices are very restricted in what they are designed to do on a direct basis over a network, and direct exchange of data between devices is thus inhibited over a network.
In the case of connecting peripherals, the cost and complexity of adding wireless local-area networking to a simple peripheral device has prevented the attachment of keyboards, mice, joysticks and other peripherals to devices via wireless networking. In practice, there are no known Wi-Fi keyboard peripherals.
Another limitation of Wi-Fi and other wireless techniques is that they require both devices to be wireless network receivers and transmitters, and that they require constant connectivity for devices to work. This consumes much power, requiring portable peripherals and devices to carry larger batteries, and requiring frequent recharging or replacement of batteries.
The Bluetooth wireless networking standard was developed as a point-to-point wireless technique for device-to-device and device-to-peripheral connection. It is specifically designed to minimize power use. Although it overcomes some of the limitations of wireless networking approaches by specifically enabling point-to-point, device-to-device communication, it still requires larger batteries, bulkier devices and requires complex protocol support. Many devices that incorporate some Bluetooth features do not allow application-level developers to access the features. For instance, one device may support transmission of address book entries to another device, but the other device, even though it has the necessary hardware support, does not implement the correct software to accept the address book transmission. Because Bluetooth software support is implemented by the device manufacturer, the device manufacturer can decide, for any reason, not to support parts of the standard.
Additionally, unlike TCP/IP and networking standards, Bluetooth is not designed for ad-hoc creation of new communication protocols. Thus, an application developer who simply wanted to use Bluetooth to implement a proprietary or industry-standard communication scheme on top of Bluetooth would be limited to the protocols the manufacturer enabled on the device. In addition, in the case of peripherals, such as Bluetooth keyboards, if a mobile device is not designed to work with a Bluetooth keyboard by the manufacturer, it is effectively impossible for an application developer to implement support for it.
Infrared light transmission, a line-of-sight wireless communication technique, was popular for one-way and two-way inter-device communication in the 1990s and still sees some use today, but has been eclipsed by Bluetooth for peripheral interconnection. The Palm series of PDA devices traditionally could accomplish the task of sending an address book contact entry from one device to another using serial binary communication over infrared communication standards such as IrDA (a high-speed, infrared serial protocol).
However, most mobile phones, PDAs, smartphones and portable devices only use infrared today as a remote control input standard, and usually only implement support for a single remote. For instance, many Macintosh computers and devices such as iPod docking stations can use an Apple remote control. Even though they have infrared receiver hardware, there is no application-level ability to receive any other infrared protocols or support any other infrared devices than the Apple remote. Many other devices with infrared support have similar limitations. The existence of an infrared receiver or transmitter on a device provides little hope that any device or protocol not supported by the manufacturer will be supported. Even though the vast majority of television and other remotes in market use uni-directional infrared transmission, and even though universal remotes have shown the versatility of this technique for device interoperability, this interoperability has rarely been demonstrated in the area of computing devices. For several years, a number of infrared keyboards were developed, and a brief era of standardization was achieved wherein a dozen or so PDA devices supported perhaps a dozen in-market portable infrared keyboards. However, the current generation of mobile devices, lacking support for the IrDA or general infrared support, cannot use these keyboards.
The Universal Serial Bus (USB) is a wired hardware communication standard and is the most common interface on mobile devices, phones, PDAs, portable computers and smartphones for charging and data communication, but is not commonly used for peripheral interconnection. Most mobile devices can be connected in a master/slave relationship with a personal computer, such that the personal computer recognizes the mobile device as a peripheral. Mobile devices usually change to a “peripheral” mode, and specialized software running on the personal computer, usually provided by the manufacturer, allows custom communication with the device, such as synchronizing address books and contacts, music, calendars and other data. Because of the master/slave design of USB, USB cannot be readily used to connect two devices, or to connect peripherals to a mobile device that itself is designed to be a peripheral, without a personal computer intermediary. Thus, address book contact exchange cannot be readily achieved by connecting two devices via USB, nor can a USB keyboard—a ubiquitous and inexpensive device—be connected to a mobile device: even though both the keyboard and the mobile device “have USB,” they are both slave devices.
Proprietary docking connectors are the most common approach to peripheral interconnection for mobile devices. PDA, phone, smartphone and portable media player manufacturers have developed custom physical and electrical connections on their devices to build an ecosystem of peripherals that only work with their devices. For instance, the Apple iPod® dock connector standard has enabled a large aftermarket ecosystem of automobile integration adapters, speakers, video playback devices, microphones, remote controls, pedometers, projectors and other peripherals. Similar approaches are used by mobile phone and portable media player manufacturers to create proprietary peripheral interfaces for remote controls, chargers and audio outputs.
Beyond physical and electrical limitations, manufacturers often develop custom protocols, inaccessible to application developers, so that even if a device exists and can be coupled to the proprietary electrical and mechanical interface, it is impossible for an application developer to support the device or access its functionality. For example, there are microphone input peripherals designed to enable audio input for iPod devices that lack a microphone. Even though they use the standard connector and have even been approved for use with some models of iPod, they cannot work with the latest iPods, merely because Apple has not provided the software support (device drivers) to allow access to them by application developers, and because there is no way for application developers to develop these device drivers or provide these device drivers to consumers.
None of the existing systems have been able to provide mobile device application developers with a reliable technique for accomplishing inter-device communication regardless of hardware design limitations and regardless of manufacturer.